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REMARKS/ARGUMENTS 

Applicant's agent appreciates the Examiner's efforts to make the claim numbering set 
forth in the Office Action of October 27, 2003 correspond to the claim numbering set forth in 
applicant's Preliminary Amendment of September 26, 2001 . Accordingly, the claim 
numbering and claims addressed in this amendment also correspond to applicant's 
Preliminary Amendment. 

In response to the Notice of Non-Compliant Amendment, applicant reordered the 
"Listing of Claims" to be in numericaJ order. 

In response to the Office Action in which the Examiner rejected the abstract of the 
disclosure, applicant amended the abstract to correct several typographical errors. In addition, 
applicant amended the paragraph on page 7 to correct a typographical error. Applicant also 
amended claim 15 to add a missing period, amended claims 27, 31, and 42 to remove the 
word "generic", which had no antecedent basis in the claims, and amended claims 45 and 47 
to recite "[t]he node" rather than "[tlhe system" in accordance with each claim's parent claim. 
Finally, applicant canceled claim 8. 

Jn the Office Action, the Examiner also rejected priorly presented independent claims 
1, 29, 44, 46, and 48 and dependent claim 49 as unpatentable, 35 USC 102(b) in view of Kay 
et al„ patent 5,247,571, September 21, 1993 (hereinafter Kay). In response thereto, applicant 
amended claims 29 and claim 46 to clarify that the "central server" and the "application" 
recited therein, respectively, interface the PSTN and are therefore not elements of the PSTN. 
Applicant amended claim 44 to clarify that the node recited therein is a "PSTN based node" 
and that this node includes a system for delivering data "to subscriber devices." Lastly, 
applicant amended claim 49 to be an independent claim that includes the limitations of claim 
48 and correspondingly, cancelled claim 48. 

Kay teaches a method for implementing a Centrex using an AIN (Advanced 
Intelligent Network) architecture. The AIN architecture comprises a plurality of central office 
switches interconnected through trunk circuits, which are used to carry telephone calls 
between the switches and terminal equipment (such as phones, modems, faxes, etc.)- The 
architecture also comprises an ISCP and a COS signaling network, which network 
interconnects the switches between each other and to the ISCP. (Kay, column 10 line 27 to 
column 11, line 9). 

Under AIN, when a calling station makes a service request (i.e., goes off-hook) and 
enters a called number, the originating switch begins by communicating through the CCIS 
network with the terminating switch that serves the called station, inquiring from this switch 
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whether the call can be completed to the called station- If the call can be completed, the 
originating and terminating switches complete the call setup by establishing a telephone 
connection between the calling and called stations using the trunks circuits that interconnect 
the switches. (Kay, Figure 3; column 13, lines 16-32). In addition to basic call setup, ADM 
also allows switches to be programmed to recognize different service triggers for a telephone 
line. When a trigger applies to a telephone line, the switch communicates with the ISCP to 
obtain additional call processing information and then uses this information to proceed with 
the call setup. (Kay> column 3, lines 28-35; column 1 1 , line 20 to column 12, line 32). 

In accordance with Kay's teaching for implementing a Centrex, a switch is 
programmed to recognize that certain of its local lines have an associated Centrex service 
(i.e., an AIN trigger is associated with the line). When an originating switch detects a service 
request (Le M detects an off-hook) on one of these lines, the switch receives the dialed digits 
from the calling station and then suspends the call. The switch then formulates a TCAP 
request message for the ISCP requesting that the ISCP provide instructions on how to process 
the call, and then sends this request message through the CCIS network to the ISCP. Upon 
receiving the message, the ISCP uses the calling number and/or dialed digits to access a local 
database in order to obtain call processing data that the originating switch needs to complete 
the call. The ISCP places the call processing data into a TCAP response message and sends 
this message back to the originating switch through the CCIS network. The originating 
switch in turn uses the call processing data to determine the terminating switch that serves the 
called station and then communicates with this switch via the CCIS network to determine if 
the call can be completed, as described above. If the call can be completed, the originating 
and terminating switches complete call setup by establishing a telephone connection between 
the calling and called stations using the trunks circuits that interconnect the switches. (Kay, 
Figure 4; column 13 line 33 to column 14, line 16). 

Kay's teachings are divergent from claim 1 and fail to teach or suggest the steps of 
claim 1. Most significantly, claim 1 recites that data is routed from a service application to a 
subscriber device via TCAP messaging. Importantly, both the service application and 
subscriber device of claim 1 interface the PSTN network through originating and terminating 
nodes and are therefore not part of the PSTN network. The only comparable elements in 
Kay's teachings to the service application and subscriber device of claim 1 are the calling 
station interfacing an originating switch and the called station interfacing a tenninating 
switch. However, in accordance with Kay, data never moves between calling and called 
stations using TCAP messaging. Kay only teaches that TCAP messaging is used for 
communications between PSTN components, or in other words, is used between the 
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originating and terminating switches in order to establish trunk circuits through which the 
calling and called stations can communicate and is used between an originating switch and the 
ISCP in order for the originating switch to obtain call processing data, All data sent between 
the calling and called stations is through the trunk circuits. 

. In addition, claim i recites that the service application creates a request message that 
includes both "data and data delivery instructions" and that a terminating node receives this 
message via the TC AP messaging and uses the enclosed instructions to aanspon the data to 
the subscriber device. Applicant's agree that Kay teaches that a calling station will send a 
"service request*' to an originating switch; however, this request as taught by Kay is simply an 
off-hook indication and is not a message including both data and data delivery instructions as 
claim 1 recites. In addition, although the calling station also communicates called station 
dialed digits to the originating switch and that the originating switch may send these digits via 
TCAP messaging to a terminating switch, Kay fails to teach or suggest that these digits are a 
message including both data and data delivery instructions or that these digits are ever 
conveyed to a called station. Furthermore, although Kay teaches that once a call is 
established, originating/terminating switches convey data through trunk circuits between 
calling and called stations, Kay fails to teach or suggest that the switches are examining these 
communications and as such, Kay fails to teach or suggest that the switches are delivering this 
data according to instructions that are accompanying the data. 

In addition, applicant agrees that in response to detecting an off-hook from a calling 
station the originating switch will contact the ISCP to obtain call processing data and that the 
switch will subsequently use this data to establish a trunk circuit. While one can possibly 
view this call processing data from the ISCP as data delivery instructions, these data delivery 
instructions are not created by the calling station, are not part of a single request message that 
also includes data from the calling station, and are not conveyed with data to a terminating 
switch and subsequently used by this terminating switch to deliver data to a called station, as 
claim 1 recites. Accordingly, Kay fails to teach or suggest claim 1- 

Tuming to amended claim 29, it recites that in delivering a request message from a 
central server to a subscriber device, the central server transports the message to a PSTN 
based node "without establishing a call" and that the PSTN based node then delivers the data 
to the subscriber device. Because the central server and subscriber device of claim 29 
interface the PSTN, Kay* s calling and called stations are the only comparable elements to the 
central server and subscriber device. However, as described above, Kay only teaches a 
calling station sending data to a called station through trunk circuits, which indicates the 
transfer is the result of establishing a call, contrary to claim 29. 
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In addition, Kay fails to teach or suggest that its calling station creates a request 
message that includes both "data and data delivery instructions," that such a message is ever 
transported from a calling station to a PSTN based node, or that a PSTN based node delivers 
data to a called station based on instructions received from a calling station, contrary to claim 
29. Again, Kay only teaches a calling station sending to a switch an off-hook indication and 
called station dialed digits. As indicated, neither an off-hook indication nor dialed digits is a 
message including both data and data delivery instructions and neither is ever conveyed to 
called station, as claim 29 recites. Similarly, while the ISCP will send call processing data to 
an originating switch (i.e., a PSTN based node), this call processing data does not originate 
from a calling station and is not associated with data from a calling station. Accordingly, Kay 
fails to teach or suggest amended claim 29. 

Turning to amended claim 44. it recites a PSTN based node with a data delivery 
. system that comprises "means for receiving a request message [that includes bothl data and 
data delivery instructions and means for delivering the data to one or more subscriber, devices 
according to the ... instructions." Again, Kay teaches thai an originating switch has means 
for detecting a calling station going off-hook; however, this off-hook is not a request message 
that includes both data and data delivery instructions as claim 44 recites. Similarly, Kay 
teaches that an originating switch has means for subsequently receiving dialed digits from a 
calling station. Assuming these dialed digits are "data", Kay fails to teach or suggest that data 
delivery instructions accompany this data or that this data is ever delivered to a subscriber 
device. Kay only teaches that the originating switch conveys these digits/data to the ISCP or 
to a terminating switch (for the purpose of establishing a trunk circuit). Similarly, assuming 
the dialed digits are "data delivery instructions", Kay fails to teach or suggest that data 
accompanies these instructions. In addition, while the originating/terminating switches of Kay 
convey data through trunk circuits between calling and called stations, Kay fails to teach or 
suggest that the switches are examining these communications and as such, Kay fails to teach 
or suggest that the switches are delivering this data according to instructions that are 
accompanying the data. 

It is further noted that while Kay teaches the originating switch receives call 
processing data from the ISCP and that one can view this call processing data as "data 
delivery instructions/' these data delivery instructions are not part of a single request message 
that also includes data that the originating switch subsequently delivers to a calling/called 
station based on the instructions, as claim 44 recites. Kay only teaches that the switch uses 
the call processing data to communicate with a terminating switch to establish a trunk circuiL 
Note further that in some cases, Kay indicates that as part of call processing, the ISCP may 
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instruct an originating switch to further communicate with a calling station by issuing a 
prompt, such as synthesized speech or tone. (Kay, column 14, lines 26-48, column 21; lines 
20-32). Importantly, these communications are still divergent from claim 44. Significantly, 
while one can possibly view these instructions from the ISCP to the originating switch as 
"data delivery instructions", Kay fails to teach or suggest that the switch also receives from 
the ISCP the data (i.e., the prompt) to be communicated to the calling station and as 
important, fails to teach or suggest that the switch has no "knowledge of the data format" 
communicated to the calling station, as claim 44 recites. Accordingly, Kay fails to teach or 
suggest amended claim 44. 

Turning to amended claim 46, it recites "a PSTN based node comprising means for 
receiving data from an application interfacing the PSTN [and] means for distinguishing the 
data as a type comprising service and implementation information wherein the 
implementation information describes how to deliver the service information/ 1 Again, the 
only elements of Kay comparable to the PSTN based node and application of amended claim 
46 are Kay's originating switch and calling station, respectively. However, as described 
above. Kay never teaches that the originating switch receives from the calling station data that 
comprises both service information and implementation information wherein the 
implementation information describes how to deliver the service information. 

Amended claim 46 further recites that the PSTN based node comprises "means for 
transmitting the data over a packet interface if the data is of the type comprising service and 
implementation information." While Kay teaches that the originating switch will deliver 
dialed digits from a calling station over a packet network to the ISCP, these teachings are still 
divergent from claim 46 because Kay teaches that this determination to send the dialed digits 
is based on automatic AIN triggers at the switch. Significantly, these triggers do not actuate 
as a result of receiving data of the type comprising service and implementation information 
from the calling station, as claim 46 recites. Similarly, while Kay teaches that the originating 
switch will deliver dialed digits from a calling station over a packet network to a terminating 
switch, the determination to send these digits is based on normal call processing procedures at 
the switch and is not the result of receiving data of the type comprising service and 
implementation information from the calling station. Accordingly, Kay fails to teach or 
suggest amended claim 46. 

Amended claim 49 recites a method executed by a service application for sending 
data through a PSTN therein the service application resides outside the PSTN " The method 
comprises the steps of creating a message that comprises both the data and "customized 
delivery options for instructing the PSTN on how to deliver the data " and ''transmitting the 
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message without establishing a call " Kay fails to teach or suggest amended claim 49 for 
several reasons. First, as described above, Kay teaches that all data sent through the PSTN by 
a device residing outside the PSTN, such as a calling station, occurs through trunk circuits, or 
in other words, is the result of establishing a call, contrary to claim 49. Second, Kay fails to 
teach or suggest that a device, such as calling station, creates a message that includes both 
data and customized delivery options and that these delivery options are for instructing the 
PSTN on how to deliver the data. Similarly, while Kay teaches that the ISCP will send call 
processing ^fiT** to an originating switch without establishing a call and this call processing 
data can be viewed as customized delivery options, the ISCP is not a service application that 
resides outside the PSTN, as claim 49 recites. Accordingly, Kay fails to teach or suggest 
amended claim 49. 

The Examiner rejected priorly presented independent claims 31,35, and 43 as 
unpatentable, 35 USC 1 03(a), over Kay in view of Willis et al., patent 6,385,647 Bl , May 7, 
2002 (hereinafter Willis). In response thereto, applicant amended claims 31 and 43 to clarify 
that the central servers recited therein interface the PSTN and are therefore not elements of 
the PSTN. 

Willis is directed at efficiently multicasting data from a source to multiple 
destinations. Willis notes that multicasting typically occurs through communications 
networks that comprise the Internet and telephony systems. The problem, however, is that the 
bandwidth requirements of the multicasted data often exceed the capabilities of these 
communications networks, making the multicast inefficient. Willis overcomes this problem 
through the use of a satellite transmission network, which provides for more efficient 
transmission of high bandwidth data. In particular, a source that needs to multicast data first 
sends the data to a source computer This source computer analyzes the data for its size and 
the distance it needs to travel to the destinations. Based on this analysis, the source computer 
either continues to route, the data through the traditional communications networks (i.e., 
Internet and telephony systems) or alternatively, through a satellite communications network. 
In either case, the data is routed over one of these networks to a receiving facility, which then 
routes the data to the intended destinations. (Willis, column 2, line 17 to column 4, line 35; 
column 9, line 58 to column 10, line 19; column 20, line 6 to column 22, line 37). 

Turning to amended claim 31, the Examiner indicates that Kay teaches all steps 
except for multicasting, which is taught by Willis. Applicant respectfully disagrees. 
Beginning with Kay, the only comparable elements to the central server and subscriber 
devices of claim 31 are Kay's calling and called stations because the central server and 
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subscriber devices interface the PSTN* Significantly, claim 3 i recites that in broadcasting 
data from the central server to subscriber devices, the central server routes the data as part of a 
request message to a PSTN based node "without establishing a call*' and the PSTN based 
node then delivers the data to the subscriber devices according to delivery instructions in the 
message. However, contrary to claim 31 and as described above, Kay teaches that all data 
sent between the calling and called stations occurs through trunk circuits, or in other words, is 
the result of establishing a call. 

In addition, Kay fails to teach or suggest that a calling station defines a request 
message that includes both data delivery instructions and data and that such a message is 
routed from a calling station to a PSTN based node, as claim 31 recites. Again* a calling 
station will send an off-hook and dialed digits to an originating switch, but this off-hook and 
these dialed digits are not messages that comprise both data and delivery instructions and 
more importantly, are not messages that comprise delivery instructions that specify a "list of 
possible subscriber devices" that are served by the node and that should receive the data, as 
claim 31 recites. Similarly, while the ISCP will send call processing data to an originating 
switch without establishing a call and this call processing data can be viewed as customized 
delivery options, the ISCP is a PSTN-based component and is therefore not equivalent to the 
central server of claim 31, which central server Only interfaces the PSTN. 

Willis also fails to teach or suggest the steps of claim 3 1 alone or in combination with 
Kay. Most significantly, Willis fails to teach or suggest that elements external to a PSTN 
network communicate through the PSTN without establishing a call. In addition, while 
applicant agrees that Willis describes elements that perform multicasting/broadcasting, Willis 
fails to teach or suggest thai any of the described elements, including the source computer and 
receiving facility, are a PSTN-based node that multicasts data, or in other words, are PSTN- 
based nodes that deliver data to one or more subscriber devices based on delivery 
instructions. 

Applicant also disagrees with the Examiner that there is motivation to combine 
multicasting as taught by Willis with the teachings of Kay. The Examiner makes particular 
reference to Kay's ISCP and the ISCP's associated database and indicates that the 
"motivation to combine the ; push* technology from Willis into the Kay network is found 
within Kay as an obvious form of information dissemination in consideration of the 
functionalities and means described therein." The only references Kay makes to the ISCP and 
the ISCP's database are with respect to switches querying the ISCP for call processing 
information based on a specific call initiated by a subscriber. It is unclear from Kay's 7 
teachings what benefit or functionality would be gained from having the ISCP spontaneously 
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send call processing information to switches, whether it be uni-cast, multicast, or broadcast. 
Accordingly, Kay and Willis, alone and in combination, fail to teach or suggest claim 31. 

Turning to claim 35, the Examiner indicates that Kay teaches all steps except for the 
incorporation of unified messaging, which is taught by Willis. Claim 35 is novel and non- 
obvious in view of Kay and Willis for the same reasons as set forth above for claim 31. 
Again, the "multi-functional server" and "subscriber" of claim 35 interface the PSTN and 
both Kay and Willis fail to teach or suggest that elements interfacing the PSTN communicate 
through the PSTN Without establishing a call," as claim 35 recites. Similarly, Kay and 
Willis fail to teach or suggest an element that interfaces the PSTN (such as a calling station) 
creating a request message that includes both "data concerning subscriber messages' 1 and 
delivery instructions "instructing [aj switch on how to deliver such data to a subscriber 
device" or that such a message is delivered to a PSTN based node from an element that 
interfaces the PSTN. 

Perhaps more importantly however, it is unclear why the use of multicasting as taught 
by Willis and as suggested by the Examiner would motive one to interface to a PSTN based 
system a "multi-functional server that receives subscriber messages from the PSTN and 
Internet" and that then uses the PSTN based system to deliver data concerning these 
subscriber messages to a subscriber without establishing a call. In particular, neither Kay nor 
Willis discusses Unified Messaging Services. In addition, because Kay is directed at using 
AIN mechanisms to trigger call setup and then establishing calls through trunk circuits, the 
obvious combination of Unified Messaging Services and Kay would be the reception of 
subscriber messages triggering Kay's system to establish a call and then delivering the 
messages to a subscriber through trunk circuits, which is not applicant's invention as recited 
by claim 35. Accordingly, Kay and Willis, alone and in combination, fail to teach or suggest 
claim 35. 

Turning to amended claim 43, the Examiner indicates that Kay teaches all steps 
except for the step of delivering the data from the service profiler to the wireless device via 
the wireless network, which is taught by Willis. Again, applicant respectfully disagrees for the 
same reasons as set forth above for claims 31 and 35. Again, the central server and service 
profiler of claim 43 are external to the PSTN and both Kay and Willis fail to teach or suggest 
that elements external to the PSTN communicate through the PSTN Without establishing a 
call/' as claim 43 recites. Similarly, Kay and Willis fail to teach or suggest an element that 
interfaces the PSTN creating a request message that includes both data and data delivery 
instructions that are used by a switch to deliver the data or that such a message is delivered to 
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a PSTN based node from an element thai interfaces the PSTN. Accordingly, Kay and Willis, 
alone and in combination, fail to teach or suggest claim 43. 


The Examiner rejected priorly presented dependent claims 2, 12, 17, 18, 25, 37, 40, 
and 42 as unpatentable, 35 USC 102(b) in view of Kay, rejected priorly presented dependent 
claims 3-7, 9, 10, 15, 19, 20, 26, 38, 36, 39, and 41 as unpatentable, 35 USC 103(a), over Kay 
in view of Willis, and rejected priorly presented dependent claims 27, 30, 45, 47, and 50 as 
unpatentable, 35 USC 103(a) in view of Kay. Each of these claims depends from an 
independent claim addressed above and is therefore novel and nonobvious in view of Kay and 
Willis for the same reasons as set forth above. 


Since Kay and Willis do not teach or suggest applicant's novel methods and 
apparatus alone or in combination as set forth in claims 1-7, 9, 10, 12, 35, 36, and 41 and 
amended claims 15, 17-20, 25-27, 29-31, 37-40, 42-47, 49. and 50, applicant submits that 
these claims are clearly allowable. Favorable reconsideration and allowance of these claims 
are therefore requested. 

Applicant eamesdy believes that this application is now in condition to be passed to / 
issue, and such action is also respectfully requested. However, if the Examiner deems it/ 
would in any way facilitate the prosecution of this application, she is invited to telephone 
applicant's agent at the number given below. 


Respectfully submitted, 
Glen Farbanish 

Reg. No, 50561 / 
TeL: (732) 699-3668 

Telcordia Technologies, Inc. 
One Telcordia Drive 
Piscataway, NJ 08854-4157 


Page IS of 18 


PAGE 28128 ' RCVD AT 4/16/2004 1:37:52 PM [Eastern Daylight Time] * SVR:USPT0-EFXRF-1/1 * DNIS:8729306 ; CSID:17323363004 * DURATION (mnvss):l1-32 


